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WEB-BASED NETWORK MONITORING TOOL 
Background of the Invention 

1 . Field of the Invention: 

The present invention relates to a monitoring tool for use in a telecommunications 
system which automatically monitors one or more automatic call distributors (ACD) and 
provides an indication of the status of such ACDs in essentially real time. 

2. Description of the Prior Art: 

Automatic call distributors (ACD) are known in the art. Such ACDs are 
telecommunications devices, used by various manufactures and service providers, to handle a 
relatively huge volume of calls and distribute them among a relatively few agents. Such ACDs 
are known to be networked and interconnected with interactive voice response units (IVR). As 
such, calls to a company's customer service telephone are provided with menu options by the 
IVR depending on the type of service required. The caller's selection is then used to route the 
call to the appropriate ACD in the network. One or more agent groups are normally affiliated 
with each of the ACDs in the network. The call is routed to an agent group and held until one 
of the agents is available to take the call. The calls are normally distributed to the agents 
according to various criteria. For example, the call may be routed to the agent in the agent group 
that has been idle the longest. Alternatively, the call may be routed to the agent based on the 
caller's telephone number or the number dialed by the caller. If all of the agents are busy, the 
call may be held in queue or routed to another agent group, for example, for a predetermined time 
period or the caller may be requested to leave a voice mail message for later call back. 

Such ACDs are known to be provided by a number of manufacturers. For 
example, Lucent Technologies, Rockwell, Toshiba and STE are all known manufacturers of 
ACDs. An important aspect of such ACDs is the efficiency by which the incoming service calls 
are handled. As such, all of the providers of such ACDs are known to provide online monitoring 
of the ACDs. Unfortunately, such systems are monitored manually on a query basis. In other 
words, service technicians must manually query or poll each of the ACDs to determine its status, 
which can be time consuming. Once an alarm condition is detected, a service technician is 
subsequently dispatched to correct the problem. Unfortunately, with such a system, an ACD can 
be out of service for several hours and perhaps days depending on the location of the service 
technician relative to the ACD and the severity of the problem. While such ACDs are out of 



service, the call answering time potentially increases, perhaps leading many customer calls 
unanswered, potentially causing customer ill will toward the company and increased call traffic 
when the ACD is returned to service. Thus, there is a need for a monitoring system which lowers 
the response time and provides continuous and automatic monitoring of the various conditions 
in order to reduce the amount of time such ACDs are out of service. 

Brief Description of the Drawings 

Various objects and advantages of the present invention will be realized upon 
consideration of the following specification and attached drawing wherein: 

FIG. 1 is a block diagram of an inbound and outbound distribution system for a 
network of automatic call distributors (ACD) in accordance with the present invention. 

FIG. 2 is an exemplary block diagram of a network of ACDs with exemplary 
agent groups associated with each of the ACDs according to the present invention. 

FIG. 3 is a detailed block diagram of a single ACD in accordance with the present 

invention. 

FIG. 4 is an exemplary home web page for an ACD in accordance with the present 
invention which provides hyperlinks to various web pages for all incoming and outgoing trunk 
groups connected to the ACD as well as auxiliary equipment associated with the ACD. 

FIGs. 5A, 5B represents an exemplary web page, linked to the web page 
illustrated in FIG 4, illustrating the status of incoming trunk groups coupled to the ACD 
illustrated in FIG. 4. 

FIGs. 6A, 6B represents an exemplary web page, linked to the web page 
illustrated in FIGs. 5 A, 5B, illustrating the trunk inventory record keeping system (TIRKS) for 
a selected trunk group illustrated in FIGs. 5A and 5B. 

FIGs. 7A, 7B represents an exemplary web page, linked to the exemplary home 
web page illustrated in FIG. 4 illustrating the status of the various expansion port network (EPN) 
connected to the ACD illustrated in FIG. 4. 

FIG. 8 represents an exemplary web page linked to the home web page illustrated 
in FIG. 4, illustrating an alarm log for the ACD illustrated in FIG. 4. 

FIG. 9 is an exemplary web page, linked to the ACD home web page illustrated 
in FIG. 4 illustrating the ACD agent status. 



FIG. 10 is an exemplary web page, linked to the EPN web page illustrated in 
FIGs. 7A, &B which illustrates the EPN cabinet stations and port assignments. 

FIG. 1 1 is an exemplary web page, linked to the home web page illustrated in 
FIG. 4, which illustrates the traffic or load of all customer care centers (CCC) and inbound traffic 
to the ACD in FIG. 4. 

Detailed Description of the Invention 

The present invention relates to a monitoring tool for use with one or more 
automatic call distributors (ACD) which automatically and continuously polls or queries the 
ACDs to monitor not only alarm conditions but other conditions, such as agent staffing levels, 
call answering time, call routing and traffic conditions. Such continuous and automatic querying 
of the ACD in accordance with the present invention is thus able to improve the overall 
efficiency of such ACDs by improving the service response time of such ACDs. In accordance 
with one aspect of the invention, the status of the ACDs may be directed to a website, for 
example, on an enterprise Intranet website to enable any of the company representatives with 
access rights to access the real time performance of the ACD network from any location. 
Another aspect of the invention is the ability to provide automatic paging for predetermined 
alarm status condition. 

Although the present invention is illustrated and described relative to Lucent 
Definity G3R ACDs, the principles of the present invention are applicable to virtually any ACD 
or other telecommunications equipment which stores status data. 

An exemplary block diagram illustrating the inbound and outbound trunks for an 
exemplary network of ACDs is illustrated in FIG. 1. As shown, the exemplary network, 
generally identified with the reference numeral 20, is shown with, for example, six (6) exemplary 
ACDs 22, 24, 26, 28, 30 and 32. As shown, the exemplary ACD network 20 may contain ACDs 
in different states in different regions in the country. For example, as shown in FIG. 1, three 
ACDs 22, 24 and 26 may be located in Illinois, designated as Illinois-1 ; Illinois-2 and Illinois-3, 
while two ACDs 28 and 30 are located in Michigan and designated as Michigan- 1 and Michigan- 
2. The sixth ACD may be located in Ohio and designated Ohio. 

Each ACD 22, 24/26, 28, 30 and 32 may include two inbound trunk groups and 
two outbound trunk groups. Fj6r example, the ACD 22 may include two inbound trunk groups 
34 and 36 from independen^ong distance carrier switches 38 and 40. In order to improve the 
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inbound reliability of the system, calls placed to a central office 42 may be routed to two 
different access tandems 44 and 46 by way of a plurality of trunks 48 and 50. The access 
tandenA 44 and 46 may also be tied together by way of intermachine trunks (IMT) 52. Separate 
trunk groups 54, 56, 58 and 59 from each of the access tandems 44 and 46 are applied to each 
of the longViistance carrier switches 38 and 40. In particular, each access tandem is connected 
to both of thee long distance carrier switches 38 and 40 by way of a plurality of trunk groups 54 
and 56. Similarly, the access tandem 46 may be connected to the long distance carrier switches 
38 and 40 by wby of a plurality of trunk groups 56 and 58. With such a configuration, should 
one of the access Widems 44 or 48 fail, calls can be routed through the other access tandem since 
both access tandems feed each of the long distance carrier switches 38 and 40; and the access 
tandems 44 and 46 aae tied together by way of the IMT 52. The exemplary in bound distribution 
system may also be configured to minimize service loss upon failure of one of the long distance 
carrier switches 38 anaUO. In particular, as mentioned above, each of the ACDs 22, 24, 26, 28, 
30 and 32 has two incoming trunk groups 34 and 36; one from each of the long distance carrier 
switches 38 and 40 respectively. Thus, should one of the long distance carrier switches 38, 40 
fail, calls can be routed ta the appropriate ACD 22, 24, 26, 28, 30 and 32 by the other long 
distance carrier switch. Similarly, should problems develop with one of the trunk inbound trunk 
groups 34 or 36, calls to the ACD can be re-routed by way of the other trunk groups to provide 
improved overall reliability of the system. 

Each of the ACDs 22, 24, 26, 28, 30 and 32 may also provided with, for example, 
two outgoing trunk groups. For example, the ACD 22 may be provided with the outgoing trunk 
groups 58 and 60. These outbound trunk groups enable outbound calls from the ACDs 22, 24, 
26, 28, 30 and 32 to be directed to central offices (not shown). In order to provide reliability of 
outgoing calls from each of the ACDs 22, 24, 26, 28, 30 and 32, each of the outgoing trunk 
^groups 58 and 60 are directed to a separate central office (not shown). 

^"^^ FIG. 2 illustrates a block diagram of an exemplary ACD network 20. As 

mentioned abovfev the ACD network in accordance with an exemplary embodiment of the 
invention includes sXaCDs 22, 24, 26, 28, 30 and 32. The exemplary ACD network 20 may 
be configured to route caite, for example, to approximately 6,000 agents, distributed in one or 
more regions around the country. Each ACD 22, 24, 26, 28, 30 and 32 may include one or more 
customer care centers (CCC) fooiandling various customer services, generally identified with 
the reference numeral 62. Each COC 62 may include one or more expansion port networks 



(EP^ft. Each EPN may be used to route calls to a plurality of agents, for example, 90 agents. 
In addition to the CCCs 62, each ACD 22, 24, 26, 28, 30 and 32 may utilize EPNs for special 
purpose applications, such as training, generally identified with the reference numeral 24, 
collections,\generally identified with the reference numeral 66 and, for example, executive 
agplications, generally identified with the reference numeral 68. 

) As discussed ^bove, each of the ACDs 22, 24, 26, 28, 30 and 32 is fed with two 

incoming trunk groups 34 and 36 (FIG. 1) and two outgoing trunk groups 58 and 60. The 
outgoing trunk groupynay be used for customer call back or transferring calls to different ACDs 
or CCC. In additio^f each of the ACDs 22, 24, 26, 28 and 30 may be connected to the other five 
ACDs by a numjtfer of trunk groups. For example, the ACD 22 may be connected to the ACD 
32 by way ofran intermachine trunk group (IMT) 68. Similarly, the ACD 22 may be connected 
to the ACDs 24, 26, 28 and 30 by way of IMT groups 70, 72, 74 and 76. As such, should one 
of theACDs or trunk groups fail, calls can be routed by way of the IMTs to other ACDs in the 
nq^work. 

FIG. 3 is a block diagram of an exemplary block diagram of a consumer voice 
network, generally identified with the reference numeral 100. For example, 800 number calls 
placed from a telephone 102 are directed to a central office, for example, the central office 42. 
The network service database 1 04 at the central office 42 determines the responsible organization 
for handling the call. In particular, the 800 number is looked up in the database 104, and an 
appropriate carrier identification code (CIC) is returned. In this example, since the call is 
directed to an 800 number, the network service database 1 04 will return a CIC directing that the 
calls be directed to an access tandem 44, 46 and a long distance carrier switch, for example, the 
long distance carrier switches 38 and 40. Each long distance carrier switch 38 and 40 includes 
a service control point (SCP) data base 104 used to look up the 800 number and direct the call 
to one of the ACDs 22, 24, 26, 28, 30 and 32 by way of one of two incoming trunk groups 34 and 
36. 

£ 5 J Initially the call is routed to an interactive voice response unit 1 06, for example, 

an IBM Direct Talk 6000, where/the caller may be given various voice menu options in which 
the customer is directed to respond by way of the touch-tone telephone 102. In addition, the 
customer may be required tcwey in a telephone number. The information input by the customer 
is then looked up on a database, such as an Ameritech Customer Information System ( ACIS) data 
base 1 06 containing customer records. The customer record information may then be provided 
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to a seWer 108, used to provide the information back to the ACD 22, 24, 26, 28, 30 and 32 and 
display me information on the screen of the next available agent. The call and the above- 
mentionectanformation are then routed to an appropriate CCC 68. In particular, the calls are 
routed to an EPN 108, which, in turn, routes the calls to the next available agent. Each agent is 
provided with a^vork station 112. All the work stations may be connected together in a network, 
for example a to&en ring network. The customer records may then be "screen popped" onto the 
agents work stations 112, when the agent picks up the call. 

Other options may be provided with the ACDs 22, 24, 26, 28, 30 and 32. For 
example, a predictive dialer 116 may be provided and connected to the ACD 22, 24, 26, 28, 30 
and 32. The predictive dialer, 116 may be used for automatic dialing for various purposes, such 
as collections. As shown in FIG. 2, the ACDs 26 and 30 are provided with predictive dialers. 
In addition, a call management system (CMS) 118 may be provided with each ACD 22, 24, 26, 
28, 30 and 32. The CMS 1 18 collects data from the ACD 22, 24, 26, 28, 30 and 32 and stores 
the data for 24 hours. The data collected by the CMS 118 is available by way of a dial-up 
modem. 

As mentioned above, each ACD 22, 24, 26, 28, 30 and 32 may be used to route 
calls to one or more EPNs 108 (FIG. 3). A typical single EPN may be used to direct calls to, for 
example, 90 customer service agents. Thus, any time there is an outage related to one of the 
ACDs 22, 24, 26, 28, 30 or 32, several problems can result. Such an outage causes an 
interruption of customer service or other function associated with the ACD. In addition, such 
outages idle a relatively significant number of customer service agents. Depending on the 
severity of the outage and availability of service technicians, such outages can thus be 
substantial. As such, various vendors of ACDs, such as Lucent Technologies, have developed 
software which allows the status of the ACD 22, 24, 26, 28, 30 and 32 to be stored and thus be 
manually polled by way of a dial-up modem with standard communications software to ascertain 
the status of the ACDs 22, 24, 26, 28, 30 and 32. With such software, it is necessary to manually 
poll the ACDs 22, 24, 26, 28, 30 and 32 on a periodic basis. For a network of ACDs, for 
example, as illustrated in FIG. 2, a considerable amount of man power is required to perform the 
manual polling of the ACDs 22, 24, 26, 28, 30 and 32. In addition, such systems are reactive. 
In other words, once an alarm condition is detected, a service technician is subsequently 
dispatched to correct the problem. Unfortunately with such prior art systems, an ACD can be 



-7- 

out of service for several hours and perhaps days depending on the severity of the problem and 
the location of the service technician relative to the ACD 22, 24, 26, 28, 30 and 32. 

In order to solve this problem, the present invention automatically and 
continuously polls or queries each of the ACDs 22, 24, 26, 28, 30 and 32 on a periodic basis, for 
example every two minutes, and provides the status of the ACDs. The system may also be used 
to monitor the load balance on each of the ACDs 22, 24, 26, 28, 30 and 32 as well as various 
other attributes of the system, for example, the call traffic to each of the agents, and the average 
amount of wait time per call. This information may then be transferred, for example, over a 
secure line, for example, to a corporate Intranet, and displayed by way of a conventional web 
browser. As known in the art, such corporate Intranet networks are normally protected by a 
corporate fire wall, which only enables authorized users to access the corporate Intranet. As 
such, anyone with access rights to the corporate Intranet can access the ACD status information 
over the Internet from virtually anywhere in the world. By providing automatic and continuous 
polling of the ACDs, the status of ACDs can be detected and adjustments made to correct 
problems before they happen. 

Exemplary web pages in accordance with the present invention, adapted to be 
displayed by way of a conventional web browser, such as the Internet Explorer and Netscape, 
are illustrated in FIGs. 4-11. Referring to FIG. 4, an exemplary ACD home page for the ACD 
28 is illustrated and generally identified with the reference numeral 130. Home pages for the 
remaining ACDs 22, 24, 26, 30 and 32 would be similar. The ACD home page 130 may be 
provided with three data boxes; a traffic load data box 1 32; an alarm status data box 134 and a 
current system status data box 136. 

The traffic load data box 1 32 is adapted to provide the traffic load of a particular 
ACD and in particular the traffic load of all of the various trunks connected to the ACD including 
inbound, outbound and intermachine trunks as well as information on the EPNs and other devices 
connected to the ACD, such as an IVR. The traffic load data box 1 32 may be provided with five 
columns 138, 140, 142, 144 and 146. Column 138 relates to the trunk group connected to the 
particular ACD. In particular, as mentioned above, each of the ACDs 22, 24, 26, 28 and 30 is 
fed from inbound trunks from the long distance carrier switches 38 and 40 (FIG. 1), identified, 
for example, as Hudson and Troy, respectively as well as the intermachine trunks (IMT) 
connected to the ACD 28 from each of the other ACDs 22, 24, 26, 28, 30 and 32. Column 138 
also lists the outbound feeds for each ACD (i.e., OUT DETROIT and OUT SOUTHFIELD) as 
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well as supplemental services, such as a direct inline dial (DID), an interactive voice response 
(IVR) unit and the contact quality center (CQC). Column 140 may be used to refer to the 
number of trunks associated with each of the trunk groups identified in co lumn 138. Column 142 
may be used to identify the number of trunks out of service, while column 144 may be used to 
display the percent occupancy rate of the various trunk groups. 

In accordance with an important aspect of the invention, traffic load information 
for all the inbound and outbound trunks to the ACD as well as to the IVR may be displayed 
graphically in column 146, for example, in the form of a bar graph. For example, as shown in 
FIG. 4 for the Troy trunk group, identified in row 150 and column 144, a 59% occupancy rate 
is indicated. This 59% occupancy rate represents the traffic load for the incoming trunk lines 
from the Troy long distance carrier switch 40 (FIG. 1). 

In one embodiment of the invention, different colors may be used to provide quick 
visual indication of the occupancy rate. For example, the color green may be used to display 
occupancy rates up to 80% while a different color such as yellow may be used to display 
occupancy rates, for example, greater than 80%. In this way, the load balance of all trunk groups 
connected to each of the ACDs 22, 24, 26, 28, 30 and 32 can be quickly checked at a glance by 
just monitoring column 146 and noting the specific color used for the bar graph. 

In addition, to the trunk groups connected to the various ACDs 22, 24, 26, 28, 30 
and 32, the traffic load data block 130 may also be used to provide access to associated 
equipment, such as EPNs and CQC (contact fluality center). As will be discussed in more detail 
below, each of the entries in column 138 of the traffic load data box 130 maybe hyperlinked to 
successive web pages which provide more detailed information. For example, FIGs. 5 A and 5B 
illustrate an exemplary web page, activated by way of the hyperlink for the Troy trunk group. 
In particular, if the "Troy" hyperlink in column 138 and row 150 of the load balance data box 
1 30 is clicked on, more detailed information regarding the trunk groups connected between Troy 
and the ACD 28 is provided. For example, FIG. 4, column 140 indicates that Troy has 708 
trunks. FIG. 5 A provides the data for those 708 trunks. For example, with reference to FIG. 5 A 
and 5B, six (6) trunk groups (TROY TGN 623, 626, 627, 629, 624, 634) are shown from the long 
distance carrier switch 40 (FIG. 1) at Troy to the ACD 28. Each trunk group contains five ISDN- 
PRI lines, which each contain 24 circuits to provide a total of 708 trunks between the long 
distance carrier switch 40 and the ACD 28. The web page illustrated in FIG. 5 A and 5B may be 
broken into a number of data boxes 150, 152, 154, 156, 158 and 160. Each data box 150-160 
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may be used to display information regarding a single trunk group, which, as mentioned above, 
may display five ISDN-PRI lines. 

Each of the data boxes 1 50- 1 60 may be provided with a plurality of columns. The 
first column 1 62 may be used to represent the trunk group number (TGN). The second column 
may be used to represent office equipment (OE). The third column may be used to provide the 
circuit identification numbers and may be hyperlinked to local assignment information for each 
circuit, for example, as illustrated in FIG. 6A and 6B. The alarm status may be provided in 
column 168 for each of the ISDN-PRI lines. The columns 171 and 173 may be used for 
miscellaneous information, such as smart jacks, if applicable. 

An important aspect of one embodiment of the invention relates to the integration 
of other data, which may be other dynamic data not retrieved from the ACD, or static data, such 
as the local circuit assignments and records. In particular, the trunk inventory record keeping 
system (TIRKS) data as illustrated in FIGs. 6A and 6B may be hyperlinked to the trunk group 
data illustrated in FIGS. 5 A and 5B. Thus, when alarm conditions are detected, the TIRKS data 
is readily available, for example, on an enterprise intranet website. As such, trouble shooting of 
alarm conditions is greatly reduced. 

Returning to the ACD home page illustrated in FIG. 4, an "ALARM STATUS" 
data box 1 34 may also be provided. As currently shown, the alarm status box 1 34 indicates that 
there are no alarms (i.e. "There are no alarms"). The alarm status box 134 may be used to 
represent alarms which may be flashing and/or displaying different colors. For example, minor 
alarms may be displayed in yellow while major alarms are displayed in red. The alarm status 
data box 134 may be hyperlinked to a historical alarm log, for example as illustrated in FIG. 8, 
which maintains the status of alarms for a predetermined period of time, such as 30 days. 

As mentioned above, the ACD home page 130 may also be provided with a 
"current system status" data box 136 which gives different types of useful information regarding 
the call traffic on the system, as well as other useful information regarding the system. For 
example, the current system status data box 136, as shown, indicates that there are 233 agents 
active and that there are 68 calls in the queue and the longest call has been in the queue for 10 
minutes, 12 seconds. The current system status box 136 may contain a hyperlink to an agent 
status web page, for example, as generally shown in FIG. 9. The agent status web page may be 
used to provide different information regarding the agent status. For example, the agent status 
web page may provide information regarding the skill level of the agent, for example as provided 
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in column 170, the number of agents active, as indicated in column 172, the number of calls in 
the queue as shown in column 174 and the longest wait for a waiting call, for example as 
illustrated in column 176, as well as information regarding the name of the gate or functional 
representation of a call queue. 

As mentioned above, the ACD home page 130, in addition to providing an 
information relating to the trunks connected to a particular ACD 22, 24, 26, 28, 30 and 32, may 
also be used to provide information regarding equipment connected to the ACDs, such as EPNs. 
As mentioned above, one or more customer care centers (CCC) may be connected to each of the 
ACDs 22, 24, 26, 28, 30 and 32. Each of the CCCs may be formed from one or more EPNs, 
which distribute the calls to the various agents at a particular location. As such, the EPNs 
associated with an ACD may be hyperlinked to an EPN web page, such as illustrated in FIG. 1 0 
which provides additional information regarding the particular EPN, such as the "port/card" 
assignment within the selected EPN cabinet. Such information is relatively useful to a service 
technician who can look up the information on the Intranet rather than looking through a number 
of detailed corporate records. 

A load balance page is illustrated in FIG. 1 1 . This home page may be provided 
to display the traffic for an entire ACD. For example, referring to FIG. 2, the ACD 28 illustrates 
a CCC in Kalamazoo with three EPNs; a CCC in Bethune with one EPN; a CCC in Southfield 
with seven EPNs; and a CCC in Saginaw with four EPNs. Referring back to FIG. 1 1 , the traffic 
load for each of the EPNs may be illustrated visually. For example, the load balance page may 
be provided with a plurality of columns 180-188. The columns 180-186 maybe used to indicate 
the port network number, the EPN or host cabinet, name, the occupancy rate and the highest 
occupancy rate ever of all of the EPNs as well as the host cabinets. The occupancy information 
may be shown graphically by way of a bar graph in column 188. For example, a left-hand 
portion 1 90 of the bar chart may be used to represent the current occupancy for the previous hour 
while the right portion 192 may be used to represent the highest occupancy ever. 

SOFTWARE 

As mentioned above, the present invention continuously and automatically polls 
the ACDs over a dial up connection, captures data stored relative to the ACDs and processes this 
data, for example, to generate the exemplary web pages illustrated in FIGs. 4 through 1 1 . The 
system in accordance with the present invention may be implemented with standard 
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communications type software, such as Procomm Plus V4.7 3 available from Symantec Corp., and 
adapted to provide continuous and automatic polling and transmission of data stored in the 
ACDs. In one embodiment of the invention, the system is adapted to transmit data, such as alarm 
data, gathered from the ACDs, to a paging platform to provide notification of the alarm status 
of the ACDs in addition to or in lieu of the web pages illustrated in FIGs. 4 through 11. The 
communication software is illustrated in FIG. 12 while the paging software is illustrated in FIG. 
13. In particular, as will be discussed in more detail below, FIG. 12 illustrates a modification 
to a standard communication software package, such as a Procomm Plus V4.7 package, for 
continuously and automatically dialing up and logging in as well as retrieving data from the 
various ACDs in the network. The paging software illustrated in FIG. 13 may be used to send 
out a display page based upon the occurrence of major and/or minor alarm conditions of the 
ACDs. The flow diagrams illustrated in FIG. 1 4 through 20 relate to processing of the data from 
the various ACDs in order to generate the various web pages illustrated in FIGs. 4 through 11. 
Exemplary software written in C + for automatically and continuously dialing up, logging and 
capturing data from the ACDs is provided in Appendix 6. Exemplary software written in C + for 
transmitting alarm status to a pager platform is provided in Appendix 7. Although the C + 
software illustrated in appendices 7 and 8 is written around the Procomm communications 
software, the principles of the present invention are applicable to virtually any standard 
communication software package. 

Appendices 1 through 5 relate to the C + files for processing the data retrieved from 
the various ACDs. In particular, Appendix 1, entitled "micl.cfg" is a configuration file for the 
ACD 28, "Michigan-1". This file, "micl.cfg", identifies all of the equipment connected to the 
ACD 28, "Michigan-1". For example, with reference to Appendix 1, the file identifies the 
various inbound trunks from the long distance carriers 38 and 40 (FIG. 1), DID trunks, the 
intermachine trunks (IMT); the outbound trunks, the interactive voice response unit (IVR) trunks, 
the contact quality center (CQC) and the various EPNs connected to the ACD 28. 

Appendix 2, entitled "micl.eqp", is an equipment file of all the various equipment 
connected to the ACD 28; (FIG. 1) "Michigan- 1 As shown in Appendix 2, all of the equipment 
being monitored for the ACD 28 (FIG. 1), "Michigan- 1" is identified in Appendix 2. 

Appendix 3 relates to a trunk file for the ACD 28 (FIG. 1), "Michigan-1 ". For 
example, page 3 of Appendix 3 identifies Troy trunk group number 629. As shown on page 3 
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of Appendix 3, Troy trunk group 629 is shown to consist of circuits 004 E 17; 005 E 17; 006 A 
17; 007 A 17 and 007 E 17, which corresponds to box 156 in FIG. 5 A. 

Appendix 4, entitled "micl .gat", relates to the agent's skill level for the ACD 28 
(FIG. 1), "Michigan- 1". This file is used to provide the agent status web page as illustrated in 
FIG. 9. 

Appendix 5, entitled "micl .pn" is a load balance file. This file is used to provide 
the load balance web page as illustrated in FIG. 1 1 . For example, as shown, this file is used to 
provide a load balance or occupancy level of the various port cabinets as well as the EPNs 
attached to the ACD 28; namely Bethune, Kalamazoo, Saginaw and Southfield. 

Referring to FIG. 12 an exemplary flow diagrams for continuously, connecting 
p to, logging into and capturing data from various ACDs is illustrated and generally identified with 

S the reference numeral 200. Initially, an ACD is selected in step 202. The system then dials into 

H and logs onto the selected ACD in step 204. After the system logs onto the selected ACD, the 

|J system^ waits for an answer back to determine if the connection was successful in step 206. If 

S not, the system proceeds to step 209 and transmits and generates a carrier failure status indication 

ife in step 209. After a successful connection, the system begins capturing available data from the 

J selected ACD in step 208 and successfully reports the carrier status in step 210. After the carrier 

j status has been reported, trunk group traffic information is received from the selected ACD in 

'( step 212. Subsequently, the alarm status is transmitted in step 214. 

In order to provide some level of reliability of the data transmitted from the ACD, 
the system may periodically check the carrier connection as illustrated in steps 216, 218, 220, 
222 and 224. Anytime a carrier failure is detected, the system proceeds to step 208 and generates 
a carrier failure indication. 

Assuming that the system is connected, the status health of the selected ACD is 
transmitted in 226, after the system checks to see if it is still connected to the carrier in step 218. 
The system retrieves the trunk group load traffic data in step 228. After again checking the 
connection of the carrier in step 220, the system retrieves the agent status data in step 230. 

In step 232, the system retrieves the IVR port status after checking the connection 
of the carrier in step 222. Subsequently, in step 234 the system retrieves all login data and 
terminates the data capture from the ACD in step 236. 
"■P^ ffi^J If aiL alarms have been detected, the system may be configured to transmit the 

alarm information t© a paging platform, for example, as illustrated in FIG. 13 in step 238. 



Subsequently, in step 240 the system selects the next ACD and loops back to step 202 to provide 
a continuous and automatic process for dialing up; logging into and capturing data from the next 
of the various ACDs in the network. 

As indicated above, the system may be provided with the ability to provide major 
and minor alarm status to a paging platform. The software for transmitting the major and minor 
alarm information to a paging platform, for example, Procomm Plus, as illustrated in FIG. 13. 
This system generally identified with the reference numeral 250 continuously loops waiting for 
major and minor alarms to be detected as mentioned above in step 238. Once the alarm 
information is detected in step 252, the alarm data may be assembled in a batch file or other file 
suitable for transmission to a paging platform. Once the alarm data is assembled in a suitable 
file, it is continuously transmitted to the paging platform in steps 256 and 258 until the paging 
platform indicates to the system 250 that the page was successfully received. 
^ £>f \. The software for processing the data captured from the ACDs is illustrated in 

FIGs. 14-20. Y IGs * 14A-C illustrates the main loop. Referring to FIGs. 14A-C, the system 
begins by initializing its arrays and opening files in steps 260 and 262. As known in the art, in 
order to determine\he time corresponding to particular status information provided in an ACD, 
all ACDs are knowrMo be provided with a real time clock. Depending on the location of the 
ACD, different ACDs in a network may be in different time zones. As such, in steps 264 and 
266, the real time data from the ACDs is^pbtained and adjusted for the particular time zone for 
the ACD in processing. Subsequently, in step 268 the data obtained from the ACD, as discussed 
above in FIG. 12, is read in step 268. In steps 270-280, the system ascertains what type of data 
was captured. For example, inVtep 270 the system determines if system health status data was 
captured. If the data with system health status, the system proceeds to step 280 and processes 
the system held data as illustrated yi FIG. 15. 

If the data is not system health status, the system next determines in 272 whether 
the data is related to alarm information. If so, the system proceeds to step 282 and processes the 
alarm information in accordance with FIG. 16. If the data is not alarm information, the system 
next determines whether the captured data was hunt group or agent status information. If the 
captured data was hunt group information as determined in step 274, the system next proceeds 
to step 284 and processes the hunt groups information as set forth in FIG. 17. If the captured 
data was not hunt group information, the system next ascertains whether the data is login status 
in step 276. If so, the system proceeds to process the login information in step 286 as illustrated 
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in FIG. 1 8. If the data is not login status information, the system checks in step 278 to determine 
whether the data is trunk information. If so, the system processes the trunk group information 
in step 288 as set forth in FIG. 19. If the captured data is not system health status data; alarm 
information; hunt group information; login status or trunk group information, the system next 
ascertains whether the data capture was load balance information. If so, the system proceeds to 
step 290 and processes the load balance information as set forth in FIG. 20. 

All of the data processing algorithms illustrated in FIGs. 1 5-20 return to the main 
loop. Subsequently, after all of the various data is processed as set forth in FIGs. 1 5 and 20. The 
system computes the summary information in steps 292 (FIG. 14B) and may load it into HTML 
files for displaying by way of the web pages illustrated in FIGs. 4-11. In particular, system 
summary information may be used for example to provide data for the ACD web page, for 
example, as illustrated in the data boxes 132, 134 illustrated in FIG. 4. In step 294, the total 
number of trunk groups is listed in column 140 in the data box 132. Next, in step 296, the total 
for the alarm status may be provided for the data box 134 (FIG. 4). Lastly, the summary 
information computed in step 292 to report the number of agents in step 298 and the blockage 
in step 300 from the information obtained in step 290 for display in the data box 136 in FIG. 4. 
In step 302, the system identifies the various login users to the ACD in the data box 136 in FIG. 
4. For example, as shown in FIG. 4, the user "barnh" is identified. Next, in step 304 the system 
processes the system health. In particular, the system checks the occupancy and idle time for 
reporting in the data box 136 in the ACD home page illustrated in FIG. 4. In step 306, the 
system reports the contact quality status (CQC) in the data box 132 on the ACD home page 1 30 
illustrated in FIG. 4. The CQC is treated like a trunk group and is reported as either "used" or 
"idle". Next, in step 308, the system reports the EPNs status. As mentioned above, the ACD 
web page includes an EPN hyperlink, linked to the various EPNs connected to the specific ACD, 
for example as illustrated in FIG. 7 A and 7B. As discussed above, this data may be used to 
provide occupancy (i.e. usage) information for the various EPNs for example as illustrated in 
column 188 in FIG. 11. 

As mentioned above, the system is adapted to provide an alarm log for each ACD. 
An exemplary alarm log is illustrated in FIG. 8. The information for the exemplary alarm log 
is generated by the system which forms a historical file for all alarms captured in step 310 as 
illustrated in FIG. 20. In step 312, the data collected above is used to create a dynamic HTML 
file to provide virtually real time data by way of a web page. 
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The software for processing the data captured from the ACD is illustrated in FIGs. 
1 5-20. Referring to FIG. 1 5 , the algorithm for processing the system health is illustrated. In step 
314, 316 and 318, system checks data captured from the ACD relating to the occupancy of the 
ACD; idle time and whether the ACD is active. In addition, in step 320 the system checks to 
determine if the ACD has been blocked out for maintenance activity. The system returns in step 
322 to the main loop to process additional data retrieved from the selected ACD. 

Alarm information is processed as illustrated in FIG. 16. In step 324, the 
equipment associated with each alarm is determined. This equipment is then cross referenced 
in step 326 to process the data retrieved with the specific equipment associated with the alarm 
(i.e., EPN Saginaw), for example as illustrated in FIG. 8. Next, in step 328 the system identifies 
the alarms in the data box 134 (FIG. 4) of the ACD web page 130. The system returns in step 
330. 

A sub-system for processing hunt group information is illustrated in FIG. 17. The 
data processed by this sub system is used to create agent status web pages as illustrated in FIG. 
9. Initially, in step 332 the system determines the status of each agent (i.e. skill level of agent; 
number of calls in the queue; longest wait for calls). In step 334, the agents are crossed reference 
to various gate groups, for example, the gates identified in FIG. 9. In step 326, the gates are 
grouped according to local assignments, for example as illustrated in FIG. 9. The information 
may be used to create a dynamic HTML file for display on a web page illustrated in FIG. 9. The 
system returns from step 340. 

Login information may be processed as illustrated in FIG. 18. This information 
is used to identify the login users and the current system status data box 136 (FIG. 4) on the ACD 
home page 130. Initially this system determines the number of active logins in step 342. For 
example, as shown in FIG. 4, the user "rbarnh" is illustrated. In step 344, the connectivity is 
reported. As shown in the data box 136 in FIG. 4, the connectivity method is shown as dial up 
versus direct connect (i.e. local log-in). In step 346, keyboarding messaging commands are 
reported. The most recent input messages by the user provide a historical audit trail of activity, 
stem returns in step 348. 

The system for processing load balance information is illustrated in FIG. 19. This 
ation is used to provide the yfoad balance information illustrated in column 192 of the 
traffic load web page illustrated yfr FIG. 2. Initially, in step 350 historical load balance data is 
read. This data is updated witll the current load balance information in step 352 and used to 
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generate a HTML load balance file. In step 354, is used to generate the web pages illustrated in 
FIGs. 4vind 11. In step 356, blockage thresholds are reported. The blockage thresholds relate 
to 0% - 180% for growth potential of capacity exhaust). This data is used for the data box 136 
of the ACQ web page 130 illustrated in FIG. 4. The system returns in step 358. 

* As mentioned above, the system may be used to generate an alarm log, for 
example as illustrated in FIG. 8. Initially in step 362, the system determines whether the alarm 
is new. If so, it determines whether the alarm is a major alarm in step 364. If the system is a 
major alarm, the system logs the alarm for transmission to a display pager in step 366. If the 
alarm is not a major alarm or if the alarm is not a new alarm, the system proceeds to step 368 for 
display on the web page illustrated in FIG. 8. The system may also include a step 370 for 
printing current alarms. Subsequently, in step 372, the historical alarm log is updated. This 
information is used in step 374 to create a dynamic HTML file for display, for example in FIG. 
8. The system returns in step 376. 



Exemplary HTML code for the web pages illustrated in FIGs 4-11 is provided in 
appendices 9-16 as indicated in the table below. 



Figure 


HTML File Name 


Appendix 


4 


micl.htm 


9 


5 


micl011.htm 


10 


6 


324230.htm 


11 


7 


miclepn.htm 


12 


8 


miclalm.htm 


13 


9 


miclagnt.htm 


14 


10 


miclE14.htm 


15 


11 


miclloacLhtm 


16 



It should be appreciated that a wide range of changes and modifications may be 
made to the embodiment of the invention as described herein. Thus, it is intended that the 
foregoing detailed descriptions be regarded as illustrative rather than limiting and that the 
following claims, including all equivalents, are intended to define the scope of the invention. 

What is claimed is: 



